Elastic Transcoder から MediaConvert への移行のススメ

動画変換処理を行う Elastic Transcorder は MediaConvert に移行することによりコストや機能に関するメリットが享受できるケースがあります。移行に当たって評価すべきことなどをまとめてみました。

#AWS Elemental MediaConvert

#Amazon Elastic Transcoder

#AWS

大前諒祐

2021.06.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。動画変換日和な今日この頃です。

前置き

動画や音声の変換処理を AWS で実施したい場合、最近は AWS Elemental MediaConvert（以下 MediaConvert）を利用する事が多いかと思います。

一方で、Amazon Elastic Transcoder（以下 Elastic Transcoder）という MediaConvert と同様に動画や音声の変換処理を行うことのできるサービスも存在します。

MediaConvert は 2017年に発表・一般提供された比較的新しいサービスであることから、それ以前に設計されたシステムでは Elastic Transcoder が稼働している事も珍しくありません。（Elastic Transcoder は 2013年発表だそうです、古参！）

ただ、Elastic Transcoder のサービスページには下記の記載があり、AWS としては MediaConvert への移行を推奨しているにも読み取れます。

AWS Elemental MediaConvert でコストを削減し、より多くの機能を取得する

AWS Elemental MediaConvert は、包括的で高度な変換機能を提供する新しいファイルベースの動画変換サービスで、オンデマンドのレートは 0.0075 USD/分からスタートします。続きを読む。

既に Amazon Elastic Transcoder を使用していますか。ステップバイステップの手順とプリセットを変換するスクリプトを含むこのガイドを使用して、MediaConvert に簡単に移行できます。

とはいえ、サービスの移行は色々と調査する事が多く腰が重くなるのも事実です。そこで、今回は Elastic Transcoder から MediaConvert への移行を検討する際に知っておきたい情報をまとめるという目的でブログを書いていきたいと思います。

本記事が「Elastic Transcoder から MediaConvert への移行は気になっているけど第一歩が踏み出せていない。。。」という方の一助になれば幸いです。

Elastic Transcoder と MediaConvert の対比

移行を検討するにあたり、Elastic Transcoder の概念が MediaConvert では何に該当するのかを理解する必要があると思いますので、簡単にまとめました。

Elastic Transcoder ... 「パイプライン」+「ジョブ」の組み合わせで動作
- パイプライン ... 変換ジョブを管理するキュー（入力情報を管理）
- ジョブ ... パイプライン中で作成する変換処理
MediaConvert ... 「キュー」+「ジョブ」の組み合わせで動作
- キュー ... 変換ジョブを管理するキュー
- ジョブ ... キューに対して作成する変換処理（入力情報を管理）

細かい機能差は色々ありますが、基本的には Elastic Transcoder の "パイプライン" が MediaConvert における "キュー" になるだけなので、すでに Elastic Transcoder を使っているのであれば、MediaConvert のキャッチアップはそこまで苦労しないかと思います。

一つポイントとしては、入力情報をどこで管理しているかが挙げられます。Elastic Transcoder ではパイプラインで入力情報（= S3 バケット）を設定するのに対し、MediaConvert ではジョブ側で入力情報（= S3 バケット）を設定します。

そのため、MediaConvert では同一キューであっても様々な S3 バケットを入力として利用できるため、より柔軟なジョブ作成が可能です。

その他、細かい使い方などについては以下ブログなどを参照ください。

MediaConvert に移行するメリット

MediaConvert に移行する事によるメリットは何か、実際に享受できるメリットはどの程度か評価する事は大切です。とりあえず移行して、結果メリットが特になかったらただ時間をかけただけになってしまうので気をつけましょう。

Elastic Transcoder から MediaConvert に移行する際の主なポイントとしては以下が挙げられます。

コスト
機能差・サービスアップデートの頻度

各ポイントについて、それぞれ見ていきます。

コスト

MediaConvert へ移行する事によるメリットを享受しやすいのがコストです。

料金レートの違い

MediaConvert は Elastic Transcoder よりも料金レートが細かく設定されているため、同じ変換処理をさせたとしても Elastic Transcoder よりもコストが下がるケースがあります。

具体的な料金レートを見てみましょう。料金レートはそれぞれ東京リージョンのものを記載しています。

Elastic Transcoder の料金レートは以下です。オーディオ専用の他、720p を境目として 2つの料金レートが用意されています。

	料金
オーディオ専用	0.00522USD
720p 未満	0.017USD
720p 以上	0.034USD

一方で、以下は MediaConvert の料金レートの一部を抜粋したものです。Elastic Transcoder は解像度が 720p 以上か以下かのみで料金レートが決まっていましたが、MediaConvert では解像度は SD/HD/4K と定義され、さらにフレームレートや変換ジョブが高度な変換を要するかどうか（ベーシックorプロフェッショナル）によってもレートが別れています。下記は一部を抜粋したのみですので、実際はさらに細かく料金レートが用意されています。

階層	パス種類	コーデック	解像度	fps	料金
ベーシック階層	1パス	AVC	SD	30fps 以下	0.0085USD
ベーシック階層	1パス	AVC	SD	30~60fps	0.0106USD
ベーシック階層	1パス	AVC	HD	30fps 以下	0.017USD
ベーシック階層	1パス	AVC	HD	30~60fps	0.0212USD
プロフェッショナル階層	1パス	AVC	SD	30fps 以下	0.0136USD
プロフェッショナル階層	1パス	AVC	SD	30~60fps	0.017USD
プロフェッショナル階層	1パス	AVC	HD	30fps 以下	0.0272USD
プロフェッショナル階層	1パス	AVC	HD	30~60fps	0.034USD

例えば、1080p の動画を変換する際に発生する料金を考えてみます。

Elastic Transcoder の場合は、「720p 以上」に該当するため料金レートは 0.034USD です。

一方で、MediaConvert の場合は「解像度 : HD」となりますが、料金レートは 0.017USD~0.0714USD と広い幅で用意されています。

変換条件や利用する機能によっては Elastic Transcoder よりも高い料金レートになる可能性もあると思いますが、単純な動画変換処理であれば料金レートを最大で半分まで落とせる場合もあります。

そのため、Elastic Transcoder で現在行なっている動画の変換条件を MediaConvert の料金レートテーブルに照らし合わせ、どのくらいのコストメリットが発生するか試算してみましょう。

リザーブド料金の存在

MediaConvert にはリザーブド料金が存在しています。EC2 等でいう所のリザーブドインスタンスの様なものです。1つのキューをリザーブド料金で購入する形になります。（実際、コンソールでは「リザーブドキュー」と記載されています）

常に MediaConvert を利用する様な環境では、このリザーブド料金を使用する事でコストメリットを出す事も可能です。

例えば、東京リージョンのリザーブド料金は 600USD/月となっていますので、これを上回るランニングコストが発生している場合は、リザーブド料金の検討をしてみると良いかもしれません。

一方で、いくつか注意点があります。

1点目は、リザーブド料金によって購入したキューには機能制限があります。今後アップデートがある可能性もありますが、現時点では以下の機能が利用できませんので注意が必要です。

Dolby Vision、高速トランスコーディング、および 8K 解像度処理はリザーブド料金ではご利用いただけません。

AWS Elemental MediaConvert 料金

2点目は、リザーブド料金は1キューあたりの費用となる事です。

例えば、MediaConvert のキューが 3つ必要なワークロード（東京リージョン）において、全てのキューにリザーブド料金を適用すると 600USD * 3 で 1800USD/月となります。そのため、MediaConvert の移行に合わせていきなりリザーブド料金を契約するのではなく、まずはオンデマンドで MediaConvert を運用し、ワークロードが安定するキューの数や構成がわかってきたらリザーブド料金を検討し、コストメリットが発生するか試算するのが良いと思います。

また、リザーブドキューをより効果的に使うための機能も MediaConvert にあったりします。キューに関する説明もされているので、よければ以下ブログも参照ください。

機能差・サービスアップデートの頻度

移行する大きなメリットは上記に挙げたコストになりますが、MediaConvert を活用する事で豊富な機能を利用する事ができるようになります。

各サービスが提供している細かい機能についてはドキュメントをそれぞれ参照頂ければと思いますが、MediaConvert に移行することによってより細かい変換ジョブを作成できるようになります。

より高画質・高品質な動画の処理
幅広いコーデック対応
ストリーミング形式での動画出力
DRM 統合
幅広いキャプション処理
etc...
Amazon Elastic Transcoder とは?
AWS Elemental MediaConvert とは何ですか?

また、サービスアップデートという視点でも近年は Elastic Transcoder のアップデートほぼなく、MediaConvert のアップデートが大半を占めています。現時点で活用したい機能がなくても、MediaConvert に移行しておくことで、将来的にアップデートの恩恵を受けられる可能性があります。

Elastic Transcoder にしか存在しない機能

Elastic Transcoder で使用している機能が MediaConvert に存在しない場合、移行が難しいケースがあります。

現時点では以下の変換処理を実施したい場合は Elastic Transcoder を利用する必要があります。

アニメーションGIF出力

FLAC、Vorbis、およびWAVオーディオのみの出力

少し古い記事では、「WebM（VP8 / VP9）の入力と出力」なども対象の機能に含まれていましたが、近年の MediaConvert のアップデートにより Elastic Transcoder にしか出来ない機能は減ってきています。現時点で実現出来ない機能であっても将来アップデートによって解消される事もありますので、機能のアップデートはウォッチしておきましょう。

How to migrate workflows from Amazon Elastic Transcoder to AWS Elemental MediaConvert

移行の進め方

Elastic Transcorder から MediaConvert への移行が決定したら実際に移行作業を進めていく形になります。

構成やスケジュール、移行に携わるメンバーのスキルなどは千差万別ですので「こうすれば良い」という銀の弾丸はありませんが、想定する一般的な流れを記載したいと思います。

Elastic Transcorder で行なっている変換処理を実現する MediaConvert ジョブの作成
既存ワークロードへの MediaConvert 組み込み
MediaConvert のパフォーマンス評価・キューの調整
サービス切り替え

想定する構成

Elastic Transcorder を継続的に利用している環境は、以下ブログの様に Lambda 等を利用した自動化ワークロードを組んでいる事がほとんどかと思います。

今回は以下の Elastic Transcorder を利用した構成を MediaConvert に移行する事を想定したいと思います。

1. Elastic Transcorder で行なっている変換処理を実現する MediaConvert ジョブの作成

まずは MediaConvert 単体で現在行なっている変換処理を実現する事を考えましょう。最初から自動化の仕組みも含めた移行を考え始めるとなかなか大変です。

Elastic Transcoder で利用しているジョブやプリセットのパラメータを元に MediaConvert のジョブを作成し、実行してみましょう。出力されたファイルを検証し、品質が担保されているか確認します。

少し古いものになりますが、Elastic Transcorder を MediaConvert に移行するにあたり、AWS がホワイトペーパーやジョブ設定を生成するためのスクリプト等を公開していたりしますので、目を通しておくと良いと思います。

2. 既存ワークロードへの MediaConvert 組み込み

MediaConvert のジョブが作成できたら、既存ワークロードに組み込む事を考えていきます。

構成としては Elastic Transcorder 利用時と同じく、S3 への PUT イベント等をトリガーに Lambda を発火し、MediaConvert のジョブを作成する流れになります。

検証環境の S3 にイベントを追加し、既存ワークロードと並行して MediaConvert を検証するもの良いかもしれません。

MediaConvert のジョブを Lambda 等から作成するにあたり、ジョブテンプレートといった概念を理解する必要が出てきますが、以下ブログなどを参照しつつ手を動かしてみてください。

3. MediaConvert のパフォーマンス評価・キューの調整

MediaConvert のジョブを既存ワークロードに組み込めたら、実際に変換ジョブを回してパフォーマンスを評価し、キューの数やキュー毎のジョブの割り振りルールなどを調整してください。

マネージドサービスであるため中身はブラックボックスではありますが、Elastic Transcorder と MediaConvert ではパフォーマンスが異なる可能性が高いため、「Elastic Transcorder でパイプライン 3つ使ってたから MediaConvert でも 3つキュー用意しておけばいいよね？」としてしまうと事故の元となります。

可能な限り本番に近いワークロードを検証環境等で実行し、期待される変換処理のスピードなどを満たしているか確認する様にしてください。

4. サービス切り替え

一通り検証・評価が完了したら本番環境の Elastic Transcorder を MediaConvert に切り替えます。

上記の通り S3 にイベントを追加することで並行して MediaConvert を稼働させる事ができるので、しばらくは両方のサービスを併用しつつ、問題ないと判断したタイミングで切り替えるorジョブを少しずつ MediaConvert に切り替えていくなど、様々なサービス切り替え方針が考えられると思います。ここは、メンテナンスに利用できる時間やコスト等を含めて検討いただくのが良いと思います。